Offer Google Antigravity as a Bot, and let a harness need one vendor's key - #808

AG-UI publishes an Antigravity integration, so this is the thirteenth harness
and mostly follows the twelve before it: a small FastAPI service, the shared
token gate, an open /health for Compose to poll, a row in the catalogue, and
the vendored mark from the same MIT set as the rest.

Two things are not like the others.

The provider is PINNED. Every other Bot reads `BOT_PROVIDER`, because they all
reach their model through LiteLLM or an equivalent and moving them is a setting.
Antigravity's SDK drives a bundled Go harness that wants a Gemini key wherever
its base url points, so a deployment that moved its other Bots to OpenAI must
not drag this one along — `bot_settings(..., pinned_provider="google")` is what
stops it. The model is still the deployment's to choose: `BOT_MODEL` names which
Gemini, and the pin only holds the provider.

The image is glibc, not musl, and the Dockerfile says why: the SDK ships a
platform wheel bundling a Go `localharness` built against manylinux_2_17, and
alpine cannot load it. Proved rather than assumed — the linux/amd64 image was
built and run, /health answered, a POST without the server token was refused
401, and the same POST with it reached the AG-UI endpoint.

`.github/published-images.json` gains the image, which is the file CI checks
against the Dockerfiles in the tree and the release derives its build matrix
from, so one entry wires both.

Worth knowing for whoever reviews the security of this: that Go harness does
real file and shell work. In this image it has no volumes and no host mount, so
its reach is the container — but it sits outside agent-computer's barriers,
authorisation and handoff entirely, which is where every other Bot's computer
work goes.

CI gives each Python Bot an environment named after it — `.venv-adk`,
`.venv-antigravity` — and `.gitignore` only knew the bare `.venv` and `venv`
spellings. Running those same commands locally, which is the obvious way to
check a Python Bot before pushing, left hundreds of megabytes of untracked
platform binaries in the tree.

Biome does not read `.gitignore`, so it needs telling separately: linting a
freshly made environment reported fifteen errors inside urllib3 and failed
`bun run lint` for reasons that had nothing to do with the change in hand.

The `google` row in `shared/model-providers.json` declares a `base_url_variable`, and this Bot
ignored it: it read `GOOGLE_API_KEY` by hand and had no way to reach a Gemini-compatible endpoint
that was not Google's. Both variable names now come from the row, so renaming either is one edit to
the file every language reads.

A base url is spelled as `endpoint=GeminiAPIEndpoint(...)`. `AntigravityAgent(base_url=...)` is a
different and mutually exclusive path, meant for unauthenticated local servers, and it drops the
key — so the test asserts the key came along rather than only grepping the source.

That url is the API ROOT, with no version path. The harness appends
`/v1beta/models/<model>:streamGenerateContent` itself, and a url carrying the version gets it twice
and 404s, which the harness reports as the unplaceable `agent executor error: Error 0, Message: Not
found`. Measured against a logging proxy, because that message names neither the url nor the status.

A Composio tool call read "Gmail fetch emails" with a muted "composio-gmail" beside it. The broker
is how the credential is held, which is an administrator's fact on the Bot's access page, not
something the person who asked about their email needs on screen — the same argument this file
already makes for relabelling research calls.

Two things kept it there. The prefix was never stripped, and the rule that drops a server the label
already names skips the label's first word, so a verb cannot be mistaken for the server. Composio
publishes `<APP>_<VERB>_<NOUN>`, so the app always leads and was always the word being skipped.

The app is still shown when the action does not name it — `FETCH_EMAILS` keeps `gmail` as its
detail. Only the broker is dropped, never what was acted upon.

The managed Bot and any harness picked during setup refuse every call that does not carry the
deployment's token, and nobody types that token anywhere: the run path attaches it by recognising
the address. The connection test did not, so testing the Bot in the box answered "The agent refused
this request. If it needs a key, add it as a header." — a refusal reported for a Bot that works, and
advice that would have broken it.

That is the worst case for a wrong verdict. The address was filled in by this deployment rather than
typed by the person reading the result, so they cannot tell this from a real refusal.

The comparison moves to `managed-endpoint.ts` and both paths call it. They had already drifted once
in the other direction — matching a single endpoint left the picked harness registered, routed to,
and answering 401 to everything — so the rule is written down once rather than twice.

An address this deployment does not run is still knocked on bare. The token's whole value is that it
is ours, and the tests pin that alongside the trailing-slash case and a deployment with no managed
Bot at all.

With the token attached the test reached the agent, got its 200, and still failed: "The agent
started answering and the connection broke." Nothing broke. The opening read stopped at an eight
kilobyte cap or the end of the stream, and an agentic harness supplies neither — Antigravity opens
with `RUN_STARTED`, ninety bytes, then goes away to call a model and run tools while holding the
stream open. The read waited out the whole run and was cut off by the request timeout.

It now stops at the first recognised AG-UI event, which is the entire question the test asks.

Events rather than bytes, deliberately: a stream of SSE comments or heartbeats would satisfy a
"something arrived" test while being no evidence of an agent at all. There is a case for that.

The tile reads `credential === "google"` to say "Needs a Gemini key", but the type it reads from
still listed three variants, so the comparison could never be true and `tsc` refused it. The desktop
app is outside the workspace and reads the catalogue over the Tauri boundary as JSON, so it cannot
import the union from shared/harnesses.ts — it keeps its own copy, and adding a variant means adding
it in both places. Said so above the type, since nothing else will.

`cargo fmt` on the catalogue parse, which rustfmt wanted joined onto one line.

Both were missed locally for the same reason: `bun run typecheck` covers the workspace, and desktop
is not in it.

Every CrewAI run started failing with `APIConnectionError: cannot import name 'CacheableResult'
from 'mcp.types'` — a model call reporting a missing import, which reads as a network fault and is
not one. Nothing in this repository changed: `agent-crewai/requirements.txt` pinned nothing, and
litellm 1.106.0 began importing a symbol that exists only in mcp 2.x while ag-ui-crewai 1.0.0
requires mcp<2. The two cannot both be satisfied.

Held litellm rather than raising mcp, because mcp>=2 is reachable only by letting the resolver walk
ag-ui-crewai back to 0.3.1 and crewai to 1.6.1 — a silent downgrade of the harness under test.
1.105.1 does not reference the symbol anywhere and leaves every other version where CI already had
it: ag-ui-crewai 1.0.0, crewai 1.15.28, mcp 1.28.1. Resolved and imported locally to check.

Only this harness is affected. The other five that name litellm resolve without mcp at all, so the
import is never reached; ADK was checked directly because it runs next in the same job.

Unrelated to the rest of this branch, and in it only because the job stops at the first harness that
fails — which left the Antigravity step skipped rather than run.

The CrewAI pin fixed CrewAI and the job walked on to LlamaIndex, which failed the same way with a
different face: `APIConnectionError: OpenAIException - No module named 'mcp'`. litellm 1.106.0
reaches for mcp during a model call and reports whatever it finds as an OpenAIException, so the
error arrives as a connection fault rather than the missing import it is.

Both ends of that break: an older mcp pinned by another dependency gives `cannot import name
'CacheableResult' from 'mcp.types'`, and no mcp at all gives `No module named 'mcp'`. I had checked
ADK, seen mcp absent, and concluded it was safe — absent is the second failure, not the absence of
one, so the remaining five are pinned together rather than one per CI round trip.

Verified by resolving and running the suite that actually failed: agent-llamaindex on litellm
1.105.1, 10 passed.